home *** CD-ROM | disk | FTP | other *** search
- Subject: Digested
- Date: Wed, 08 Jun 1994 16:12:38 +1000
- From: Warwick Allison <warwick@cs.uq.oz.au>
- Precedence: bulk
-
-
- Annius:
- > [key:action rather than action:key]
-
- I don't see a clear advantage in either method, but I suspect action:key
- is best, since it is uniform. For example, if an application called READER
- has three features "Open", "Close", "Quit", then it has three things to
- find matches for:
-
- Reader.Open.Key
- Reader.Close.Key
- Reader.Quit.Key
-
- and it simply matches them against each line in the APPL-DEF.SYS file.
-
- However, with key:action, what is it meant to do? It would have to search
- for matches using some sort of wildcard (in the search string!):
-
- Reader.Open.Key.*
- Reader.Close.Key.*
- Reader.Quit.Key.*
-
- then look at the last part of the matched string!
-
- This is very different from Xdefaults, and very complicated. The idea
- of Xdefaults is that an application gives a full string (like
- Reader.Quit.Key), and the defaults manager provides the righthand-string
- which matches it. It's not only for keys, it could be anything.
-
- An advantage of action:key is that the key can be specified using
- multiple notations. eg. user could use scancodes of THEIR MACHINE.
-
- *.SaveAs: 0x87001994
-
- > 'The other way round' also provides a way of definining other things than
- > key shortcuts, such as interface appearance and what have we.
-
- Which way? action:key does, not key:action...
-
- action:key:
-
- *Dialog*.Confirm.Key: Return
- *Dialog*.Confirm.Colour: Green
-
-
- key:action:
- Dialog*Key.Return: Confirm
- Dialog*Colour.Green: Confirm
- # huh?
-
- An advantage of key:action is that it allows multiple keys for the same
- action:
-
- Dialog*Key.Return: Confirm
- Dialog*Key.Ctrl-Y: Confirm
-
- ... but how do you show that in a menubar anyway!
-
-
- I now have no qualms about ^A or whatever. An app which uses this simple
- APPL-DEF.SYS file will be configurable to whatever the user wants. We still
- need a std set of key bindings... they will be the std APPL-DEF.SYS file,
- but it's now possible to please all the people all the time.
-
-
- Annius:
- > *active-window*.*key*.*ctl-w: Close
- > *top-window*.*key*.*ctl-u: Close
- >
- > Hm. There should be a way for a program that does NOT support the distinction
- > active/top to find both of these entries. Warwick, any suggestions?
-
- Just a problem with key:action. Use:
-
- *close*.key: ctl-u
- *close-active*.key: ctl-w
-
- This brings up the issue of order of patterns. I suggest we adopt the
- Xdefaults method whereby each line overrides previous lines. This allows
- the user to continously refine their environment by adding to the end
- of the APPL-DEF.SYS file. In implementation, the app just scans form
- beginning to end, applying each pattern.
-
-
- Michel Forget:
- >Annius:
- >[> *active-window*.*key*.*ctl-w: Close
- >[> *top-window*.*key*.*ctl-u: Close
- >
- >[Annius goes on to explain the details.]
- >
- >Annius, I feel that this is too specific. Making a distiction between
- >the top window and the active window only applies to Edith. No other
- >program I have seen (ever) have made this distiction.
-
- Michel misunderstands the purpose of the appl-def.sys file. In this file,
- all bindings are defined, even masterbrowse.pipe-through-Jive.key.
- Applications supporting appl-def.sys will include a file like this:
-
- # Standard bindings:
- *close...
- ...
-
- and a file like this:
-
- # TurboFooWriter bindings:
- TurboFooWriter.enter-blitz-mode.key: ctrl-A
- ...
-
-
- The installation process will search for a appl-def.sys file. If not found,
- it copies the standard bindings in. It appends the app bindings. All done.
-
- The user may then use a Defaults Manager to edit anything they dislike,
- including removing the `TurboFooWriter.enter-blitz-mode.key' definition
- because they already have `*.enter-blitz-mode.key' from another piece
- of software they installed.
-
-
- --
- Warwick
-
-